COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	THE COMMON BUSINESS COMMUNICATION LANGUAGE
C00012 ENDMK
C⊗;
THE COMMON BUSINESS COMMUNICATION LANGUAGE


	Here are some  ideas about the  value of a  %2common business
communication   language%2    (CBCL   for   short)   and   what   its
characteristics might be.

	The need  for  such a  language was  suggested  to me  by  an
article by Paul  Baran that appeared in %2Public  Interest%1 in 1965.
In  this article, Baran  envisaged a  world of the  future in which
companies would be well  equipped with on-line computer systems.
The inventory  control computer of  company A
would write on  the screen of  a clerk  in the  purchasing
department a statement that 1000 gross  of such-and-such pencils were
needed and  that they should be purchased from  company B.  The clerk
would turn  to her  typewriter and  type out  a purchase  order.   At
company B another clerk would receive  the purchase order and turn to
her  terminal and  tell the  computer to  arrange to ship  the pencils.
Eliminating both clerks by  having the
computers  speak directly  to  each other  was not  mentioned
Perhaps the author felt  that he was already straining  the
credulity of his audience.

	Suppose we  wish to eliminate the  clerks by
having  the computers speak directly  to each other.   %1What are the
requirements?%1

	First, computers do communicate directly now.  In the late
1950s the Social Security Administration announced a format for
IBM  seven channel magnetic tape on which  it was prepared to receive
reports of earnings  and payroll deductions.   Note the  limitations:
(i)  magnetic   tapes  are  mailed  rather   than  direct  electronic
communication - admittedly entirely appropriate in this case.  (ii) A
single fixed kind of message with a fixed  set of parameters for each
report.    (iii)  There is only one receiver of information which can
dictate the format.   Today information is often exchanged electronically
among
computer systems belonging to different organizations, but this is usually
by specific treaty betwen the two organizations, but sometimes a group
that  will  be communicating  has  agreed on  formats.
An example is the U.S. Navy's system for exchanging  information
among ships about what their radars and other sensors can see so that
each  ship can  have the  full  radar picture  acquired by  the whole
fleet.  In connection  with the extension of  the system to NATO,  it
was  completely  redesigned,  and  on a  designated  day,  all  users
switched to the new system.

	Our goal is more ambitious in the following respects:

	1.  A  common language  is  to  be adopted  that  can express
business communications.  For example, requests for price quotations,
offers  to buy  and sell,  queries about  delivery times  and places,
inquiries about the status of delayed orders, references to  standard
commercial legal agreements.  If possible, the same language should
with only different primitives should suffice to communicate the Navy's
or the FAA's radar information or a request from one state's department
of motor vehicles to another's for a list of a person's traffic
convictions.

	2. Any organization should  be able to communicate with  any other
without pre-arrangement  over ordinary dial-up telephone connections.
Of course, this requires  authentication procedures and  verification
of authorization procedures,  but let us not be  unduly distracted by
the security aspects of computing lest we end up with a secure method
of communication and nothing to say.

	3. The  system  should  be open  ended  so that  as  programs
improve, programs that  can at first only order  by stock numbers can
later be programmed  to inquire about  specifications and prices  and
decide  on  the best  deal.    This  requires that  each  message  be
translatable into  a human-comprehensible form and that each computer
have a  way  of  referring  messages  it is  not  yet  programmed  to
understand to humans.   When a new type of message  is to displace an
old one,  the programs should send both
until all the receivers can understand the
new form.   Thus the  crises of cutover days, as  in the naval
example, could be eliminated.

	We are not  now interested  in the low-level  aspects of  the
message formats,  i.e. what kinds  of bit streams  and what  kinds of
modems, except to  remark that the system should avoid traps in these
areas,  and  the  users  should  be  able  to  change  their  systems
asynchronously.

	We do not have a final proposal but here are some ideas:

	1. The messages are lists of items punctuated by parentheses.
The lead item of each list identifies the type of message and is used
to determine  how to interpret  the rest.   The  items may be  either
sublists or atoms.  If  an item is a sublist, its first element tells
how to interpret it.   Atoms are  binary numbers of say  32 bits.   A
dictionary tells what each means.  Other forms of data
may   be  used  provided  they   are  demarcated  by  appropriate
punctuation and provided they are pointed at from lists that tell how
they are to be interpreted.

	2. Here are some examples:

	a. (REQUEST-QUOTE (YOUR-STOCK-NUMBER A7305) (UNITS 100))

	b. (REQUEST-QUOTE (PENCILS #2) (GROSS 100))

	c.  (REQUEST-QUOTE  (ADJECTIVE  (PENCILS #2)  YELLOW)  (GROSS
100))

	d.   (WE-QUOTE   (OUR-STOCK-NUMBER   A7305)   (QUANTITY  100)
(DELIVERY-DATE 3-10-77) (PRICE $1.00))

	e. (PLEASE-SAY (IOTA (X) (AND (RED X)

It  appears  that  some  items  may  require  a  variable  number  of
modifiers.

	As  a toy  example,  imagine writing  conventions  that would
permit any Monopoly-like game to  be played by independently  written
programs.  Suppose that  the moves are communicated to  a referee who
receives requests to roll the dice and returns information about what
squares the pieces landed on and what "chance" cards were drawn.  The
programs would  communicate offers to  buy and sell directly  to each
other and to the "banker".